Repository navigation
analytics: Charge driver verdicts agree with the row's printed values and points - #2501
andremiliano wants to merge 1 commit into
Conversation
… and points A driver row prints the value and its baseline at display precision and the term's rounded points, but the verdict compared the raw values. So a row could read "51 bpm, 51 bpm baseline, 0 pts" and say "above baseline, limiting recovery", and skin temperature could say "near baseline" beside -1 pt. The effect (supporting / limiting) now comes from the points, and the direction from the printed values. When the printed values tie but the term still moved the score, the verdict says "slightly" above or below; when a printed difference is worth 0 points it says the difference is too small to change Charge; skin temperature is near baseline exactly when it cost nothing. Both platforms: ChargeDrivers.swift and its Kotlin twin RecoveryDrivers.kt. Six new verdicts, as catalog keys (nine locales) and Android string resources (eight locales), with the verdict-catalog contract pin moving from 12 to 18. Parity is pinned by a Swift oracle: the Swift chargeDrivers output over a 288-case grid (values either side of baseline and on the display-rounding edges, skin drift inside and outside the old band) is pasted verbatim into ChargeDriverVerdictOracleTest, which the Kotlin twin reproduces line for line. The existing ryanbr#51 half-tie expectation moves to "slightly below baseline, limiting recovery" on both sides: it prints 30 ms against a 30 ms baseline at -1 pt. Refs ryanbr#2466 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Superseded on the main fix, but not on all of it, so please read the second half before writing this off. Thanks @andremiliano. #2466 was one of the most useful reports in a while: it named three separate contradictions, located each one by file and line, worked out that the verdict was comparing raw values while the row printed rounded ones, and predicted that the verdict-catalog pin would go from 12 to 18. It did. Back-solving your 14/100 figure through That work landed from #2468 via #2500, as 6151113 and a0bf1b6, before this arrived: effect from the rounded points, direction from the displayed precision, and the pin moved to 18. Your suggested 70-adds and 60-does-not values are what shipped. Two independent people solving the same report is a good problem to have, and the only reason yours is the one being retired is order of arrival. One part of this is NOT superseded and is worth having on its own: Also still open ground, from your own "related, smaller" note: the classic Today breakdown states skin temperature twice, once as a driver row and once as the relative row via |
What this PR does
Makes each Charge "What shaped it" verdict agree with what its own row prints (#2466).
A driver row prints the value and its baseline at display precision, plus the term's rounded points. The verdict, however, compared the raw values. So a row could read
51 bpm · 51 bpm baseline · 0 pts — above baseline, limiting recovery, and skin temperature could saynear baselinebeside−1 pt.Now:
slightly above/below baseline, …above/below baseline, too small to change Chargenear baselineexactly when it cost 0 points.Scores and points are unchanged. Only the verdict wording is selected differently.
Type of change
How it was tested
swift testinPackages/StrandAnalyticspasses (2067 tests). This includes a newtestVerdictsAgreeWithThePrintedValuesAndPointscovering each case above. The Not working on macOS with Intel processor #51 half-tie pin moves toslightly below baseline, limiting recovery, since it prints 30 ms against a 30 ms baseline at −1 pt.chargeDriversover a 288-case grid and pasted its output verbatim into the newChargeDriverVerdictOracleTest. The grid covers HRV, resting HR and respiration either side of baseline and on the display-rounding edges, skin drift inside and outside the old ±0.3 °C band, and two sleep qualities. The Kotlin twin reproduces every line. That test also asserts that everyChargeDriverVerdictmaps to a Swift catalog string../gradlew testFullDebugUnitTestshows 6466 tests. Locally, 2 fail on this Mac:RecoveryDriversTest.driverPointRoundingUsesNearestWithHalfTiesAwayFromZeroandissue51NegativeHalfTie…. Both fail identically on unmodifiedmainon this machine (expected:<-0.5> but was:<-0.4999999999999929>, before any verdict assertion), so I'm relying on CI's Linux runner for those two.compileFullDebugKotlinsucceeds.Tools/i18n_audit.py --ci origin/mainpasses.test_home_i18npasses, with its verdict-key pin moved from 12 to 18.doc_comment_lintpasses.parity_ratchet.py --base origin/main --offlinereports only the "base authority cannot be reproduced" error, which pristinemainreports identically, plus a "debt decreased" warning..rounded(). It's a local value insidechargeDrivers, like the existingpointshelper, so it adds no unpaired declaration.Checklist
android/(except the two pre-existing local float failures noted above)docs/CONTRIBUTING.mdTranslations for the six new strings are machine-assisted and follow each locale's existing verdict wording. I haven't had native speakers review them.
Related issues
Refs #2466
🤖 Generated with Claude Code